home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / SS0288.ZIP / SS0288_1.TXT < prev    next >
Text File  |  1992-06-01  |  33KB  |  750 lines
  1. ======================================================================
  2.     Microsoft Product Support Services Application Note (Text File)
  3.                SS0288: RELOCATABLE OBJECT MODULE FORMAT
  4. ======================================================================
  5.                                                    Revision Date: 5/92
  6.                                                       No Disk Included
  7.  
  8. The following information applies to to the Microsoft products listed
  9. below.
  10.  
  11.  --------------------------------------------------------------------
  12. | INFORMATION PROVIDED IN THIS DOCUMENT AND ANY SOFTWARE THAT MAY    |
  13. | ACCOMPANY THIS DOCUMENT (collectively referred to as an            |
  14. | Application Note) IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY      |
  15. | KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO    |
  16. | THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A     |
  17. | PARTICULAR PURPOSE. The user assumes the entire risk as to the     |
  18. | accuracy and the use of this Application Note. This Application    |
  19. | Note may be copied and distributed subject to the following        |
  20. | conditions: 1) All text must be copied without modification and    |
  21. | all pages must be included; 2) If software is included, all files  |
  22. | on the disk(s) must be copied without modification [the MS-DOS(R)  |
  23. | utility DISKCOPY is appropriate for this purpose]; 3) All          |
  24. | components of this Application Note must be distributed together;  |
  25. | and 4) This Application Note may not be distributed for profit.    |
  26. |                                                                    |
  27. |    Copyright 1992 Microsoft Corporation.  All Rights Reserved.     |
  28. |    Microsoft, MS-DOS, QuickC, and QuickPascal are registered       |
  29. |    trademarks and Windows, QuickBasic, and Visual Basic are        |
  30. |    trademarks of Microsoft Corporation.                            |
  31. |                                                                    |
  32.  --------------------------------------------------------------------
  33.  
  34.  
  35. APPLICABLE PRODUCTS
  36. ===================
  37.  
  38. This application note applies to all versions of the following
  39. Microsoft language products:
  40.  
  41.    Microsoft Basic
  42.    Microsoft C
  43.    Microsoft C++
  44.    Microsoft COBOL
  45.    Microsoft FORTRAN
  46.    Microsoft Macro Assembler (MASM)
  47.    Microsoft Pascal
  48.    Microsoft QuickBasic(TM)
  49.    Microsoft QuickC(C)
  50.    Microsoft QuickC for Windows(TM)
  51.    Microsoft QuickPascal(C)
  52.    Microsoft Visual Basic(TM)
  53.    
  54.    
  55.                            TABLE OF CONTENTS
  56.                           ==================
  57.                                    
  58.                                                                Section
  59.                                                                -------
  60. Introduction                                                         1
  61. The Object Record Format                                             1
  62. Frequent Object Record Subfields                                     1
  63. Order of Records                                                     1
  64. Record Specifics                                                     1
  65. 80H THEADR--Translator Header Record                                 1
  66. 82H LHEADR--Library Module Header Record                             2
  67. 88H COMENT--Comment Record                                           2
  68. 88H IMPDEF--Import Definition Record (Comment Class A0, Subtype 01)  2
  69. 88H EXPDEF--Export Definition Record (Comment Class A0, Subtype 02)  2
  70. 88H INCDEF--Incremental Compilation Record (Cmnt Class A0, Sub 03)   2
  71. 88H LNKDIR--C++ Directives Record (Comment Class A0, Subtype 05)     2
  72. 88H LIBMOD--Library Module Name Record (Comment Class A3)            2
  73. 88H EXESTR--Executable String Record (Comment Class A4)              2
  74. 88H INCERR--Incremental Compilation Error (Comment Class A6)         2
  75. 88H NOPAD--No Segment Padding (Comment Class A7)                     2
  76. 88H WKEXT--Weak Extern Record (Comment Class A8)                     2
  77. 88H LZEXT--Lazy Extern Record (Comment Class A9)                     3
  78. 88H PharLap Format Record (Comment Class AA)                         3
  79. 8AH or 8BH MODEND--Module End Record                                 3
  80. 8CH EXTDEF--External Names Definition Record                         3
  81. 8EH TYPDEF--Type Definition Record                                   3
  82. 90H or 91H PUBDEF--Public Names Definition Record                    3
  83. 94H or 95H LINNUM--Line Numbers Record                               3
  84. 96H LNAMES--List of Names Record                                     4
  85. 98H or 99H SEGDEF--Segment Definition Record                         4
  86. 9AH GRPDEF--Group Definition Record                                  4
  87. 9CH or 9DH FIXUPP--Fixup Record                                      4
  88. A0H or A1H LEDATA--Logical Enumerated Data Record                    5
  89. A2H or A3H LIDATA--Logical Iterated Data Record                      5
  90. B0H COMDEF--Communal Names Definition Record                         5
  91. B2H or B3H BAKPAT--Backpatch Record                                  5
  92. B4H or B5H LEXTDEF--Local External Names Definition Record           5
  93. B6H or B7H LPUBDEF--Local Public Names Definition Record             5
  94. B8H LCOMDEF--Local Communal Names Definition Record                  5
  95. BCH CEXTDEF--COMDAT External Names Definition Record                 5
  96. C2H or C3H COMDAT--Initialized Communal Data Record                  5
  97. C4H or C5H LINSYM--Symbol Line Numbers Record                        6
  98. C6H ALIAS--Alias Definition Record                                   6
  99. C8H or C9H NBKPAT--Named Backpatch Record                            6
  100. CAH LLNAMES--Local Logical Names Definition Record                   6
  101. Appendix 1: CodeView Extensions                                      6
  102. Appendix 2: Microsoft MS-DOS Library Format                          6
  103.  
  104.  
  105. INTRODUCTION
  106. ============
  107.  
  108. This document is intended to serve a purpose that up until now has
  109. been performed by the LINK source code: to be the official definition
  110. for the object module format (the information inside .OBJ files)
  111. supported by Microsoft's language products. The goal is to include all
  112. currently used or obsolete OMF record types, all currently used or
  113. obsolete field values, and all extensions made by Microsoft, IBM, and
  114. others.
  115.  
  116. The information provided here has been consolidated from many other
  117. documents: "The MS-DOS Encyclopedia" by Microsoft Press, an OMF386
  118. document from IBM that was made available by the Joint Development
  119. Agreement, the "PharLap 386|Link Reference Manual," the Intel 8086
  120. object module specification (Intel Technical Specification 121748-
  121. 001), and internal Microsoft documents. Where there have been
  122. conflicts, the current LINK source code has decided which information
  123. is correct.
  124.  
  125. The  audience  for  this document is expected to  be  technical,  with
  126. background knowledge of the process by which source code is  converted
  127. into an executable file in the MS-DOS or OS/2 environment. If you need
  128. more  tutorial information, "The MS-DOS Encyclopedia" is a good  place
  129. to start.
  130.  
  131.  
  132. THE OBJECT RECORD FORMAT
  133. ========================
  134.  
  135. Record Format
  136. -------------
  137.  
  138. All object records conform to the following format:
  139.  
  140.                           <------Record Length in Bytes----->
  141.    1         2            <variable>    1
  142.    Record    Record       Record        Checksum or 0
  143.    Type      Length       Contents
  144.  
  145. The Record Type field is a 1-byte field containing the hexadecimal
  146. number that identifies the type of object record.
  147.  
  148. The Record Length field is a 2-byte field that gives the length of the
  149. remainder of the object record in bytes (excluding the bytes in the
  150. Record Type and Record Length fields). The record length is stored
  151. with the low-order byte first. An entire record occupies 3 bytes plus
  152. the number of bytes in the Record Length field.
  153.  
  154. The Record Contents field varies in size and format, depending on the
  155. record type.
  156.  
  157. The Checksum field is a 1-byte field that contains the negative sum
  158. (modulo 256) of all other bytes in the record. In other words, the
  159. checksum byte is calculated so that the low-order byte of the sum of
  160. all the bytes in the record, including the checksum byte, equals 0.
  161. Overflow is ignored. Some compilers write a 0 byte rather than
  162. computing the checksum, so either form should be accepted by programs
  163. that process object modules.
  164.   
  165.   NOTES
  166.   
  167.   The maximum size of the entire record (unless otherwise noted for
  168.   specific record types) is 1024 bytes.
  169.  
  170.   For LINK386, the format is determined by the least-significant bit
  171.   of the Record Type field. An odd Record Type indicates that certain
  172.   numeric fields within the record contain 32-bit values; an even
  173.   Record Type indicates that those fields contain 16-bit values. The
  174.   affected fields are described with each record. Note that this
  175.   principle does not govern the Use32/Use16 segment attribute (which
  176.   is set in the ACBP byte of SEGDEF records); it simply specifies the
  177.   size of certain numeric fields within the record. It is possible to
  178.   use 16-bit OMF records to generate 32-bit segments, or vice versa.
  179.  
  180.   LINK ignores the value of the checksum byte, but some other
  181.   utilities do not. Microsoft's Quick languages write a 0 byte instead
  182.   of computing a checksum.
  183.  
  184.  
  185. FREQUENT OBJECT RECORD SUBFIELDS
  186. ================================
  187.  
  188. The contents of each record are determined by the record type, but
  189. certain subfields appear frequently enough to be explained separately.
  190. The format of such fields is below.
  191.  
  192. Names
  193. -----
  194.  
  195. A name string is encoded as an 8-bit unsigned count followed by a
  196. string of count characters. The character set is usually some ASCII
  197. subset. A null name is specified by a single byte of 0 (indicating a
  198. string of length 0).
  199.  
  200. Indexed References
  201. ------------------
  202.  
  203. Certain items are ordered by occurrence and are referenced by index.
  204. The first occurrence of the item has index number 1. Index fields may
  205. contain 0 (indicating that they are not present) or values from 1
  206. through 7FFF. The index number field in an object record can be either
  207. 1 or 2 bytes long. If the number is in the range 0-7FH, the high-order
  208. bit (bit 7) is 0 and the low-order bits contain the index number, so
  209. the field is only 1 byte long. If the index number is in the range 80-
  210. 7FFFH, the field is 2 bytes long. The high-order bit of the first byte
  211. in the field is set to 1, and the high-order byte of the index number
  212. (which must be in the range 0-7FH) fits in the remaining 7 bits. The
  213. low-order byte of the index number is specified in the second byte of
  214. the field. The code to decode an index is:
  215.    
  216.    if (first_byte & 0x80)
  217.         index_word = (first_byte & 7F) * 0x100 + second_byte;
  218.    else
  219.         index_word = first_byte;
  220.  
  221. Type Indexes
  222. ------------
  223.  
  224. Type Index fields occupy 1 or 2 bytes and occur in PUBDEF, LPUBDEF,
  225. COMDEF, LCOMDEF, EXTDEF, and LEXTDEF records. They are encoded as
  226. described above for indexed references, but the interpretation of the
  227. values stored is governed by whether the module has the "new" or "old"
  228. object module format.
  229.  
  230. "Old" versions of the OMF (indicated by lack of a COMENT record with
  231. comment class A1), have Type Index fields that contain indexes into
  232. previously seen TYPDEF records. This format is no longer produced by
  233. Microsoft products and is ignored by LINK if it is present. See the
  234. section of this document on TYPDEF records for details on how this was
  235. used.
  236.  
  237. "New" versions of the OMF (indicated by the presence of a COMENT
  238. record with comment class A1), have Type Index fields that contain
  239. proprietary CodeView information. For more information on CodeView,
  240. see Appendix 1.
  241.   
  242.   NOTE: Currently, the linker does not perform type checking.
  243.  
  244. Ordered Collections
  245. -------------------
  246.  
  247. Certain records and record groups are ordered so that the records may
  248. be referred to with indexes (the format of indexes is described in the
  249. "Indexed References" section of this document). The same format is
  250. used whether an index refers to names, logical segments, or other
  251. items.
  252.  
  253. The overall ordering is obtained from the order of the records within
  254. the file together with the ordering of repeated fields within these
  255. records. Such ordered collections are referenced by index, counting
  256. from 1 (index 0 indicates unknown or not specified).
  257.  
  258. For example, there may be many LNAMES records within a module, and
  259. each of those records may contain many names. The names are indexed
  260. starting at 1 for the first name in the first LNAMES record
  261. encountered while reading the file, 2 for the second name in the first
  262. record, and so forth, with the highest index for the last name in the
  263. last LNAMES record encountered.
  264.  
  265. The ordered collections are:
  266.  
  267.    Names       Ordered by occurrence of LNAMES records and
  268.                names within each. Referenced as a name
  269.                index.
  270.                
  271.    Logical     Ordered by occurrence of SEGDEF records in
  272.    Segments    file. Referenced as a segment index.
  273.                
  274.    Groups      Ordered by occurrence of GRPDEF records in
  275.                file. Referenced as a group index.
  276.                
  277.    External    Ordered by occurrence of EXTDEF, COMDEF,
  278.    Symbols     LEXTDEF, and LCOMDEF records and symbols
  279.                within each. Referenced as an external name
  280.                index (in FIXUP subrecords).
  281.                
  282.  
  283. Numeric 2- and 4-Byte Fields
  284. ----------------------------
  285.  
  286. Words and double words (16- and 32-bit quantities) are stored in Intel
  287. byte order (lowest address is least significant).
  288.  
  289. Certain records, notably SEGDEF, PUBDEF, LPUBDEF, LINNUM, LEDATA,
  290. LIDATA, FIXUPP, and MODEND, contain size, offset, and displacement
  291. values that may be 32-bit quantities for Use32 segments. The encoding
  292. is as follows:
  293.  
  294.  - When the least-significant bit of the record type byte is set (that
  295.    is, the record type is an odd number), the numeric fields are 4
  296.    bytes.
  297.  
  298.  - When the least-significant bit of the record type byte is clear,
  299.    the fields occupy 2 bytes. The values are zero-extended when
  300.    applied to Use32 segments.
  301.  
  302.   NOTE: See the description of SEGDEF records in this document for an
  303.   explanation of Use16/Use32 segments.
  304.  
  305.  
  306. ORDER OF RECORDS
  307. ================
  308.  
  309. The sequence in which the types of object records appear in an object
  310. module is fairly flexible in some respects. Several record types are
  311. optional, and if the type of information they carry is unnecessary,
  312. they are omitted from the object module. In addition, most object
  313. record types can occur more than once in the same object module. And
  314. because object records are variable in length, it is often possible to
  315. choose between combining information into one large record or breaking
  316. it down into several smaller records of the same type.
  317.  
  318. An important constraint on the order in which object records appear is
  319. the need for some types of object records to refer to information
  320. contained in other records. Because the linker processes the records
  321. sequentially, object records containing such information must precede
  322. the records that refer to the information. For example, two types of
  323. object records, SEGDEF and GRPDEF, refer to the names contained in an
  324. LNAMES record. Thus, an LNAMES record must appear before any SEGDEF or
  325. GRPDEF records that refer to it so that the names in the LNAMES record
  326. are known to the linker by the time it processes the SEGDEF or GRPDEF
  327. records.
  328.  
  329. The record order is chosen so that linker passes through an object
  330. module are minimized. Microsoft LINK makes two passes through the
  331. object modules: the first pass may be cut short by the presence of the
  332. Link Pass Separator COMENT record; the second pass processes all
  333. records.
  334.  
  335. For greatest linking speed, all symbolic information should occur at
  336. the start of the object module. This order is recommended but not
  337. mandatory. The general ordering is:
  338.  
  339. Identifier Record(s)
  340. --------------------
  341.  
  342.     NOTE: This must be the first record.
  343.    
  344.    THEADR or LHEADR record
  345.  
  346. Records Processed by LINK Pass 1
  347. --------------------------------
  348.    
  349. The following records may occur in any order but they must precede the
  350. Link Pass Separator if it is present:
  351.    
  352.    COMENT records identifying object format and extensions
  353.    
  354.    COMENT records other than Link Pass Separator comment
  355.    
  356.    LNAMES or LLNAMES records providing ordered name list
  357.    
  358.    SEGDEF records providing ordered list of program segments
  359.    
  360.    GRPDEF records providing ordered list of logical segments
  361.    
  362.    TYPDEF records (obsolete)
  363.    
  364.    ALIAS records
  365.    
  366.    PUBDEF records locating and naming public symbols
  367.    
  368.    LPUBDEF records locating and naming private symbols
  369.    
  370.    COMDEF, LCOMDEF, EXTDEF, LEXTDEF, and CEXTDEF records
  371.     
  372.     NOTE: This group of records is indexed together, so external name
  373.     index fields in FIXUPP records may refer to any of the record
  374.     types listed.
  375.  
  376. Link Pass Separator (Optional)
  377. ------------------------------
  378.  
  379. COMENT class A2 record indicating that Pass 1 of the linker is
  380. complete. When this record is encountered, LINK stops reading the
  381. object file in Pass 1; no records after this comment are read in Pass
  382. 1. All the records listed above must come before this COMENT record.
  383.  
  384. For greater linking speed, all LIDATA, LEDATA, FIXUPP, BAKPAT, INCDEF,
  385. and LINNUM records should come after the A2 COMENT record, but this is
  386. not required. In LINK, Pass 2 begins again at the start of the object
  387. module, so these records are processed in Pass 2 no matter where they
  388. are placed in the object module.
  389.  
  390. Records Ignored by LINK Pass 1 and Processed by LINK Pass 2
  391. -----------------------------------------------------------
  392.    
  393. The following records may come before or after the Link Pass
  394. Separator:
  395.    
  396.    LIDATA, LEDATA, or COMDAT records followed by applicable FIXUPP
  397.    records
  398.    
  399.    FIXUPP records containing only THREAD subrecords
  400.    
  401.    BAKPAT and NBKPAT FIXUPP records
  402.    
  403.    COMENT class A0, subrecord type 03 (INCDEF) records containing
  404.    incremental compilation information for FIXUPP and LINNUM records
  405.    
  406.    LINNUM and LINSYM records providing line number and program code or
  407.    data association
  408.  
  409. Terminator
  410. ----------
  411.    
  412.    MODEND record indicating end of module with optional start address
  413.    
  414.  
  415. RECORD SPECIFICS
  416. ================
  417.  
  418. Details of each record (form and content), together with historical
  419. notes and comments on usage, are presented in the sections that
  420. follow.
  421.  
  422. Conflicts between various OMFs that overlap in their use of record
  423. types or fields are marked.
  424.  
  425. Below is a combined list of record types defined by the Intel 8086 OMF
  426. specification and record types added after that specification was
  427. finished. Titles in square brackets ([]) indicate record types that
  428. have been implemented and that are described in this document. Titles
  429. not in square brackets indicate record types that have not been
  430. implemented and are followed by a paragraph of description from the
  431. Intel specification.
  432.  
  433. For unimplemented record types, a subtle distinction is made between
  434. records that LINK ignores and those for which LINK generates an
  435. "illegal object format" error condition.
  436.  
  437. Records Currently Defined
  438. -------------------------
  439.    
  440.    6EH     RHEADR   R-Module Header Record
  441.                     This record serves to identify a module that has
  442.                     been processed (output) by LINK-86/LOCATE-86. It
  443.                     also specifies the module attributes and gives
  444.                     information on memory usage and need. This record
  445.                     type is ignored by Microsoft LINK.
  446.                     
  447.    70H     REGINT   Register Initialization Record
  448.                     This record provides information about the 8086
  449.                     register/register-pairs: CS and IP, SS and SP, DS
  450.                     and ES. The purpose of this information is for a
  451.                     loader to set the necessary registers for
  452.                     initiation of execution. This record type is
  453.                     ignored by Microsoft LINK.
  454.                     
  455.    72H     REDATA   Relocatable Enumerated Data Record
  456.                     This record provides contiguous data from which a
  457.                     portion of an 8086 memory image may eventually be
  458.                     constructed. The data may be loaded directly by
  459.                     an 8086 loader, with perhaps some base fixups.
  460.                     The record may also be called a Load-Time
  461.                     Locatable (LTL) Enumerated Data Record. This
  462.                     record type is ignored by Microsoft LINK.
  463.                     
  464.    74H     RIDATA   Relocatable Iterated Data Record
  465.                     This record provides contiguous data from which a
  466.                     portion of an 8086 memory image may eventually be
  467.                     constructed. The data may be loaded directly by
  468.                     an 8086 loader, but data bytes within the record
  469.                     may require expansion. The record may also be
  470.                     called a Load-Time Locatable (LTL) Iterated Data
  471.                     Record. This record type is ignored by Microsoft
  472.                     LINK.
  473.                     
  474.    76H     OVLDEF   Overlay Definition Record
  475.                     This record provides the overlay's name, its
  476.                     location in the object file, and its attributes.
  477.                     A loader may use this record to locate the data
  478.                     records of the overlay in the object file. This
  479.                     record type is ignored by Microsoft LINK.
  480.                     
  481.    78H     ENDREC   End Record
  482.                     This record is used to denote the end of a set of
  483.                     records, such as a block or an overlay. This
  484.                     record type is ignored by Microsoft LINK.
  485.                     
  486.    7AH     BLKDEF   Block Definition Record
  487.                     This record provides information about blocks
  488.                     that were defined in the source program input to
  489.                     the translator that produced the module. A BLKDEF
  490.                     record will be generated for every procedure and
  491.                     for every block that contains variables. This
  492.                     information is used to aid debugging programs.
  493.                     This record type is ignored by Microsoft LINK.
  494.  
  495.    7CH     BLKEND   Block End Record
  496.                     This record, together with the BLKDEF record,
  497.                     provides information about the scope of variables
  498.                     in the source program. Each BLKDEF record must be
  499.                     followed by a BLKEND record. The order of the
  500.                     BLKDEF, debug symbol records, and BLKEND records
  501.                     should reflect the order of declaration in the
  502.                     source module. This record type is ignored by
  503.                     Microsoft LINK.
  504.                   
  505.    7EH     DEBSYM   Debug Symbols Record
  506.                     This record provides information about all
  507.                     local symbols, including stack and based symbols.
  508.                     The purpose of this information is to aid debug-
  509.                     ging programs. This record type is ignored by 
  510.                     Microsoft LINK.
  511.                           
  512.    [80H]   [THEADR] [Translator Header Record]
  513.                           
  514.    [82H]   [LHEADR] [Library Module Header Record]
  515.                           
  516.    84H     PEDATA   Physical Enumerated Data Record
  517.                     This record provides contiguous data,
  518.                     from which a portion of an 8086 memory
  519.                     image may be constructed. The data
  520.                     belongs to the "unnamed absolute segment"
  521.                     in that it has been assigned absolute
  522.                     8086 memory addresses and has been
  523.                     divorced from all logical segment
  524.                     information. This record type is ignored
  525.                     by Microsoft LINK.
  526.                           
  527.    86H     PIDATA   Physical Iterated Data Record
  528.                     This record provides contiguous data,
  529.                     from which a portion of an 8086 memory
  530.                     image may be constructed. It allows
  531.                     initialization of data segments and
  532.                     provides a mechanism to reduce the size
  533.                     of object modules when there is repeated
  534.                     data to be used to initialize a memory
  535.                     image. The data belongs to the "unnamed
  536.                     absolute segment." This record type is
  537.                     ignored by Microsoft LINK.
  538.                           
  539.    [88H]   [COMENT] [Comment Record]
  540.                           
  541.    [8AH/8BH] [MODEND] [Module End Record]
  542.                           
  543.    [8CH]   [EXTDEF] [External Names Definition Record]
  544.                           
  545.    [8EH]   [TYPDEF] [Type Definition Record]
  546.                           
  547.    [90H/91H] [PUBDEF] [Public Names Definition Record]
  548.                           
  549.    92H     LOCSYM   Local Symbols Record
  550.                     This record provides information about
  551.                     symbols that were used in the source
  552.                     program input to the translator that
  553.                     produced the module. This information is
  554.                     used to aid debugging programs. This
  555.                     record has a format identical to the
  556.                     PUBDEF record. This record type is
  557.                     ignored by Microsoft LINK.
  558.                           
  559.    [94H/95H] [LINNUM] [Line Numbers Record]
  560.                           
  561.    [96H]   [LNAMES] [List of Names Record]
  562.                           
  563.    [98H/99H] [SEGDEF] [Segment Definition Record]
  564.                           
  565.    [9AH]   [GRPDEF] [Group Definition Record]
  566.                           
  567.    [9CH/9DH] [FIXUPP] [Fixup Record]
  568.                           
  569.    9EH     (none)   Unnamed record
  570.                     This record number was the only even
  571.                     number not defined by the original Intel
  572.                     specification. Apparently it was never
  573.                     used.  This record type is ignored by
  574.                     Microsoft LINK.
  575.                           
  576.    [A0H/A1H] [LEDATA] [Logical Enumerated Data Record]
  577.                           
  578.    [A2H/A3H] [LIDATA] [Logical Iterated Data Record]
  579.  
  580.    A4H     LIBHED   Library Header Record
  581.                     This record is the first record in a library
  582.                     file. It immediately precedes the modules
  583.                     (if any) in the library. Following the
  584.                     modules are three more records in the
  585.                     following order: LIBNAM, LIBLOC, and LIBDIC.
  586.                     This record type is ignored by Microsoft
  587.                     LINK.
  588.                         
  589.    A6H     LIBNAM   Library Module Names Record
  590.                     This record lists the names of all the
  591.                     modules in the library. The names are listed
  592.                     in the same sequence as the modules appear
  593.                     in the library. This record type is ignored
  594.                     by Microsoft LINK.
  595.                         
  596.    A8H     LIBLOC   Library Module Locations Record
  597.                     This record provides the relative location,
  598.                     within the library file, of the first byte
  599.                     of the first record (either a THEADR or
  600.                     LHEADR or RHEADR record) of each module in
  601.                     the library. The order of the locations
  602.                     corresponds to the order of the modules in
  603.                     the library. This record type is ignored by
  604.                     Microsoft LINK.
  605.                         
  606.    AAH     LIBDIC   Library Dictionary Record
  607.                     This record gives all the names of public
  608.                     symbols within the library. The public names
  609.                     are separated into groups; all names in the
  610.                     nth group are defined in the nth module of
  611.                     the library. This record type is ignored by
  612.                     Microsoft LINK.
  613.                         
  614.    [B0H]   [COMDEF] [Communal Names Definition Record]
  615.                         
  616.    [B2H/B3H] [BAKPAT] [Backpatch Record]
  617.                         
  618.    [B4H]   [LEXTDEF] [Local External Names Definition Record]
  619.                         
  620.    [B6H/B7H] [LPUBDEF] [Local Public Names Definition Record]
  621.                         
  622.    [B8H]   [LCOMDEF] [Local Communal Names Definition Record]
  623.                         
  624.    BAH/BBH COMFIX   Communal Fixup Record
  625.                     Microsoft doesn't support this never-
  626.                     implemented IBM extension. This record type
  627.                     generates an error when it is encountered by
  628.                     Microsoft LINK.
  629.                         
  630.    BCH     CEXTDEF  COMDAT External Names Definition Record
  631.                         
  632.    C0H     SELDEF   Selector Definition Record
  633.                     Microsoft doesn't support this never-
  634.                     implemented IBM extension. This record type
  635.                     generates an error when it is encountered by
  636.                     Microsoft LINK.
  637.                         
  638.    [C2H/C3] [COMDAT] [Initialized Communal Data Record]
  639.                         
  640.    [C4H/C5H] [LINSYM] [Symbol Line Numbers Record]
  641.                         
  642.    [C6H]   [ALIAS]  [Alias Definition Record]
  643.                         
  644.    [C8H/C9H] [NBKPAT] [Named Backpatch Record]
  645.                         
  646.    [CAH]   [LLNAMES] [Local Logical Names Definition Record]
  647.                         
  648.    [F0H]            [Library Header Record]
  649.                     Although this is not actually an OMF record
  650.                     type, the presence of a record with F0H as
  651.                     the first byte indicates that the module is
  652.                     a Microsoft library. The format of a library
  653.                     file is given in Appendix 2.
  654.  
  655.    [F1H]            [Library End Record]
  656.                         
  657.  
  658. 80H THEADR--TRANSLATOR HEADER RECORD
  659. ====================================
  660.  
  661. Description
  662. -----------
  663.  
  664. The THEADR record contains the name of the object module. This name
  665. identifies an object module within an object library or in messages
  666. produced by the linker.
  667.  
  668. History
  669. -------
  670.  
  671. Unchanged.
  672.  
  673. Record Format
  674. -------------
  675.  
  676.    1    2           1            <-String Length->  1
  677.    80   Record      String       Name String        Checksum
  678.         Length      Length
  679.    
  680. The String Length byte gives the number of characters in the name
  681. string; the name string itself is ASCII. This name is usually that of
  682. the file that contains a program's source code (if supplied by the
  683. language translator), or may be specified directly by the programmer
  684. (for example, TITLE pseudo-operand or assembler NAME directive).
  685.   
  686.   NOTES
  687.   
  688.   The name string is always present; a null name is allowed but not
  689.   recommended (because it doesn't provide much information for a
  690.   debugging program).
  691.   
  692.   In object modules generated by Microsoft compilers, the name string
  693.   indicates the full path and filename of the file that contained the
  694.   source code for the module.
  695.   
  696.   This record, or an LHEADR record must occur as the first object
  697.   record. More than one header record is allowed (as a result of an
  698.   object bind, or if the source arose from multiple files as a result
  699.   of include processing).
  700.  
  701. Examples
  702. --------
  703.  
  704. The following THEADR record was generated by the Microsoft C Compiler:
  705.  
  706.       0   1   2   3   4   5   6   7   8   9   A   B   C D  E  F  
  707. 0000  80  09  00  07  68  65  6C  6C  6F  2E  63  CB           ...hello.c
  708.                                                         
  709.  
  710. Byte 00H contains 80H, indicating a THEADR record.
  711.  
  712. Bytes 01-02H contain 0009H, the length of the remainder of the record.
  713.  
  714. Bytes 03-0AH contain the T-module name. Byte 03H contains 07H, the
  715. length of the name, and bytes 04H through 0AH contain the name itself
  716. (HELLO.C).
  717.  
  718. Byte 0BH contains the Checksum field, 0CBH.
  719.  
  720.  
  721. 82H LHEADR--LIBRARY MODULE HEADER RECORD
  722. ========================================
  723.  
  724. Description
  725. -----------
  726.  
  727. This record is very similar to the THEADR record. It is used to
  728. indicate the name of a module within a library file (which has an
  729. internal organization different from that of an object module).
  730.  
  731. History
  732. -------
  733.  
  734. This record type was defined in the original Intel specification with
  735. the same format but with a different purpose, so its use for libraries
  736. should be considered a Microsoft extension.
  737.  
  738. Record Format
  739. -------------
  740.  
  741.    1    2           1            <-String Length->  1
  742.    82   Record      String       Name String        Checksum
  743.         Length      Length
  744.  
  745.  
  746.   NOTE: In LINK, THEADR, and LHEADR records are handled identically.
  747.   See Appendix 2 for a complete description of Microsoft's library
  748.   file format.
  749.  
  750.